Click here to return to the VHDL Reference Guide. (last edit: 24. september 2012)

Coding Standards

Coding standards are divided into two categories. Lexical coding standards, which control text layout, naming conventions and commenting, are intended to improve readability and ease of maintenance. Synthesis coding standards, which control VHDL style, are intended to avoid common synthesis pitfalls and find synthesis errors early in the design flow.
The following lists of coding standards will need to be modified according to the choice of tools and personal preferences.

Lexical Coding Standards

Limit the contents of each VHDL source file to one entity and its architectures, one package and its package body, or several related configurations. Source file names should relate to the file contents (e.g. EntityName.vhdl, PackageName.vhdl or configs.vhdl).
Adopt a naming convention for architectures (e.g. Reference, Behaviour, RTL, GateLevel, TestBench).
Write only one declaration or statement per line.
Use indentation as shown in the examples.
Be consistent about the case of keywords (e.g. lower case), predefined names (e.g. upper case), and user defined names (e.g. first letter a capital). User defined names should be meaningful and informative, although local names (e.g. loop parameters) may be terse.
Label all processes and concurrent assignments, both as documentation and to aid debugging.
Write comments to explain (not duplicate) the VHDL code. It is particularly important to comment interfaces (e.g. generics, ports, parameters and packages).
Use constants and attributes wherever possible, instead of directly embedding literal numbers and strings in declarations and statements. Write use clauses at the top of each entity, package or configuration, to make dependencies easy to find.

Synthesis Coding Standards

Partition the design into small functional blocks, and use a behavioural style for each block. Avoid gate level descriptions except for critical parts of the design.
Have a well defined clocking strategy, and implement that strategy explicitly in VHDL (e.g. single clock, multi-phase clocks, gated clocks, multiple clock domains). Ensure that clock and reset signals in VHDL are clean (i.e. not generated from combinational logic or unintentionally gated).
Have a well defined (manufacturing) testing strategy, and code up the VHDL appropriately (e.g. all flipflops resettable, test access from external pins, no functional redundancy).
Every VHDL process should conform to one of the standard synthesizable process templates (see Process).
VHDL processes describing combinational and latched logic must have all of their inputs in the sensitivity list.
Combinational processes must not contain incomplete assignments, i.e. all outputs must be assigned for all combinations of input values.
Processes describing combinational and latched logic must not contain feedback, i.e. signals and variables assigned as outputs from the process must not be read as inputs to the process.
Clocked processes with a sensitivity list must have only the clock and any asynchronous control inputs (usually reset or set) in the sensitivity list. Clocked processes without a sensitivity list must have only one wait statement, of the form wait until clock_edge_expression, as the first executable statement in the process.
Avoid unwanted latches. Unwanted latches are caused by incomplete assignments in an unclocked process.
Avoid unwanted flipflops. Flipflops are synthesized when signals are assigned in a clocked process, or whe variables assigned in a clocked process retain their value between process executions (and thus between clock cycles).
All internal state registers must be resettable, in order that the Register Transfer Level and gate level descriptions can be reset into the same known state for verification. (This does not apply to pipeline or synchronization registers.)
For finite state machines and other sequential circuits with unreachable states (e.g. a 4 bit decade counter has 6 unreachable states), if the behaviour of the hardware in such states is to be controlled, then the behaviour in all 2N possible states must be described explicitly in VHDL, including the behaviour in unreachable states. This allows safe state machines to be synthesized. Avoid delays in signal assignments, except where necessary to solve the problem of delta delay clock skew at register transfer level.
Do not initialise signals or variables to values other than 'U' or 'X'. Take great care when using types with no uninitialised value (e.g. integers), because the VHDL simulation will not reveal initialisation problems.
Do not write VHDL code which relies on the order of values within an enumeration type, because the order might be changed during optimization. Such code is also harder to maintain.
Signals and variables of type INTEGER should have a range constraint, otherwise they will synthesize to 32 bit busses.
Check carefully any VHDL code which uses dynamic indexing (i.e. an index expression containing signals or variables), loop statements, or arithmetic operators, because such code can synthesize to large numbers of gates which can be hard to optimize.